1. Introduction
L’ingénierie des exigences est d’une importance capitale, surtout en Ingénierie Système. En général les exigences sont exprimées par des ingénieurs dédiés à cette activité. La complexité des systèmes modernes (embarqués, communicants, critiques, …) rendent cruciale cette analyse.
|
Besoins, exigences : question de vocabulaire
La difficulté de l’emploi massif de l’anglais fait qu’il existe souvent une confusion entre les termes anglais et leurs traduction française. Nous précisons donc ici notre utilisation des termes. |
- Requirements
-
Exigences, c’est à dire :
une fonction ou une propriété que doit satisfaire le système considéré.
Par nature une exigence doit pouvoir être vérifiable.
En génie logiciel on parle plus classiquement des spécifications ("spec") pour parler des contraintes à respecter pour un système.
Les ingénieurs systèmes ont depuis longtemps intégré le terme d’exigences comme traduction directe de requirement.
- Besoins
-
Il s’agit des exigences du client. En UML™ on va plus les retrouver dans les cas d’utilisation. Ils sont à l’origine des requirements tels que définis plus haut.
Il est important pour une exigence qu’elle ne soit pas ambiguë (contrairement au terme "en" dans la consigne exprimée par la maman dans l’illustration ci-dessous : "Ramène moi 1 bouteille de lait. S’il y a des oeufs, ramène m’en 6.").
2. Fondements
On abordera :
-
L’organization des Requirements
-
Les Requirements properties
-
Les Requirements links
-
Les Requirements Diagrams
-
Les considérations sur la traçabilité
-
Annotations des Requirements
-
Les Use Case Diagrams
|
L’ingénierie des exigences est une discipline à part entière et nous n’abordons ici que les aspects en lien avec la modélisation. Voir le livre de référence pour plus de détails ([Sommerville1997]) ou le guide de l’AFIS ([REQ2012]). |
3. L’organisation des Requirements
Il ne s’agit pas ici de revenir sur les exigences elles-même, mais plutôt de voir comment SysML™ permet de les exprimer, de les manipuler et surtout de les lier avec le reste du système.
3.1. Représentation de base
Un Requirement en SysML™ n’est qu’un bloc particulier.
|
Définition :
A requirement specifies a capability or condition that must (or should) be satisfied… A requirement is defined as a stereotype of UML Class… |
3.2. Différents types d’organisation
L’ingénierie des exigences aboutit généralement à une liste organisée d’exigences, que ce soit en terme de fonctionnelles/non fonctionnelles, de prioritaires/secondaires, etc. Le principal support de SysML™ à cette organisation, outre la possibilité de les annoter (cf. section Stéréotyper les exigences), consiste à utiliser les packages.
Plusieurs types d’organisations sont possibles :
-
Par niveau d’abstraction
-
Besoins généraux (en lien avec les use cases par exemple)
-
Besoins techniques (en lien avec les éléments de conception)
-
-
Par point de vue
-
Besoins principaux (en lien avec les use cases)
-
Besoins spécifiques :
-
Fonctionnels
-
Marketing
-
Environnementaux
-
Business
-
…
-
-
-
etc.
3.3. Tableaux de Requirements
Les requirements sont habituellement stockés dans des tableaux (feuilles excel le plus souvent!). Il est donc recommandé par le norme et possible dans de nombreux outils de représenter les exigences sous forme tabulaire.
|
Définition :
The tabular format is used to represent the requirements, their properties and relationships… |
La plupart des outils modernes permettent le passage entre outils classiques de gestion des exigences (comme DOORS™) et outils de modélisation SysML™ (comme Modelio, illustré ci-dessous).
4. Les Requirements properties
À partir du moment où on commence à définir des propriétés pour les éxigences, on peut considérer que l’on est à la frontière avec la phase d’analyse des exigences.
Il est possible d’indiquer un certain nombre de propriétés sur un requirement :
-
priority (
high,low, …) -
source (
stakeolder,law,technical, …) -
risk (
high,low, …) -
status (
proposed,approved, …) -
verification method (
analysis,tests, …)
Dans le cadre du module MPA nous ne retiendrons comme attribut d’un requirement que son identifiant et le texte le désignnat (les deux attributs obligatoire). La priorité sera donné par le client en terme de cycle (on traitera en premier les requirements prioritaires).
class ObtenirHoraires <<requirement>> {
Text = "Le logiciel doit fournir les horaires rapidement."
Id = "14.2"
}
5. Les Requirements links
Les principales relations entre requirements sont :
- Containment
-
Pour décrire la décomposition d’une exigence en plusieurs sous-exigences (⊕–). Typiquement dès qu’une exigence est exprimée avec une conjonction "et" ("La voiture doit être rapide et économe.").
- Refinement
-
Pour décrire un ajout de précision (
<<refine>>), comme par exemple une précision. - Derivation
-
Pour indiquer une différence de niveau d’abstraction (
<<deriveReqt>>), par exemple entre un système et un de ses sous-systèmes.
|
Lorsqu’une exigence possède plusieurs cas |
|
Il existe ensuite les relations entre les besoins et les autres éléments de modélisation
(les block ou les class principalement) comme |
6. Les Requirements Diagrams
Voici un exemple de req un peu plus étoffé, tiré de la norme (voir aussi Exemples de _rationale_ et _problem_ (tiré de <<SysML>>)) :
7. Stéréotyper les Requirements
Tout comme pour n’importe quel bloc, il est possible de stéréotyper les requirements. Ceci permet de se définir ses propres priorités et classifications. Quelques exemples de stéréotypes utiles :
-
<<interfaceRequirement>>,<<physicalRequirement>>, … -
<<FunctionalRequirement>>,<<nonFunctionalRequirement>>
8. Annotations des Requirements
Il est possible d’annoter les éléments de modélisation en précisant les raisons (rationale) ou les éventuels problèmes anticipés (problem).
9. Les considérations sur la traçabilité
Une fois que les requirements ont été définis et organisés, il est utile de les lier au moins aux use cases
(en utilisant <<refine>> par exemple) et aux éléments structurels (en utilisant <<satisfy>> par exemple), mais ceci
sera abordé dans la partie transverse.
|
En général chaque requirement devrait être relié à au moins un use case (et vice-versa!). |
10. Les Use Case Diagrams
Bien que nous traitions les cas d’utilisation dans la partie comportement, nous les abordons ici du fait de leur proximité avec les requirements.
Ce diagramme est celui que vous avez appris l’an dernier en UML™.
|
Un acteur représente un rôle joué par un utilisateur humain. Il faut donc plutôt raisonner sur les rôles que sur les personnes elles-mêmes pour identifier les acteurs. |
11. Exigences et tests
11.1. Principes
Pour ce qui ce concerne ce module nous allons nous contenter de maintenir des matrices croisant les exigences d’un côté et les tests de l’autre.
Par exemple :
Dans la réalité, les entreprises industrialisent le processus de vérification des exigences en utilisant des outils adaptés :
12. Exemple complet
En prenant un exemple tiré de l’exemple du Radio Réveil…
12.1. Le texte du cahier des charges
Le texte complet de l’exemple ne précise pas le cahier des charges de l’Autoradio (AR), considérant que tout le monde sait ce que c’est!
Rédigeons tout de même quelques extraits (numérotés) de texte possible :
-
L’AR est un dispositif qui permet d’écouter la radio de manière confortable et interactive.
-
L’AR doit être capable de mémoriser un certain nombre de station différentes.
-
L’Utilisateur de l’AR doit pouvoir choisir sa station parmis un choix donné.
-
L’Utilisateur de l’AR doit pouvoir régler le niveau sonore.
-
L’Utilisateur de l’AR doit pouvoir chercher une station en "balayant" les ondes FM.
-
…
12.2. Expression des exigences
Nous pouvons, en analysant ce cahier des charges, déduire un certain nombre d’exigences. Nous les écrivons ici sous forme tabulaire, puis en utilisant le langage Gherkin.
Version tabulaire :
Exemple de version textuelle formattée :
#encoding: utf-8
Feature: Scénario simple d'utilisation de l'AutoRadio (AR)
In order to vérifier que le son marche
As an utilisateur lambda
I should be able to exécuter ces scénarios et constater les effets
Scenario: Augmenter le son
Given un AR avec le son à 0
When Je presse le bouton "Volume +"
Then Le son passe à 1
And Je commence à entendre la radio
12.3. Plan de test
Créer un plan de test consiste à prévoir l’ensemble des tests à l’avance de manière à prévoir la couverture de ces tests.
12.4. Analyse et la conception
Dans un cycle classique ("en V" par exemple), les modèles sont réalisés avant l’implémentation (codage).
Dans un cycle Agile, chaque cycle possèdera ses modèles, eux aussi versionnés, qui eux aussi évolueront en même temps que le code.
12.5. Lien et traçabilité
Plus encore que dans les méthodes classiques, il conviendra de vérifier que code et modèles sont bien cohérents. On pourra donc :
-
générer les codes à partir des modèles
-
générer les modèles à partir des codes (cf. commentaires)
-
utiliser des outils intégrés comme eclipse
-
avoir un plan systématique de révision code/modèle
-
…
package demo;
class Controller {}
class EmbeddedAgent {}
class PowerManager {}
/**
* @extends Controller
* @extends EmbeddedAgent
* @navassoc - - 1..* PowerManager
* @note this is a note
*/
class SetTopController implements URLStreamHandler {
public String name;
int authorizationLevel;
void startUp() {}
void shutDown() {}
void connect() {}
}
/** @depend - friend - SetTopController */
class ChannelIterator {}
interface URLStreamHandler {
void OpenConnection();
void parseURL();
void setURL();
void toExternalForm();
}
13. En résumé
Les exigences sont très importantes en ingénierie système, du fait de la multiplication des sous-systèmes et donc des intermédiaires (fournisseurs, sous-traitants, etc.) avec qui les aspects contractuels seront souvent basés sur ces exigences.
Il n’est donc pas étonnant qu’un diagramme et des mécanismes dédiés aient été prévus en SysML™.
| Exigences | Structure | Comportement | Transverse | |
|---|---|---|---|---|
Organisation |
|
|||
Analyse |
|
|
|
|
Conception |
|
|||
Implémentation |
|
En terme de démarche, il est classique d’avoir de nombreux aller-retour entre la modélisation des exigences et la modélisation du système lui-même (cf. Exemple de démarche (_SYSMOD Zigzag pattern_) (tirée de [TestsIndustriels2009])).
14. Pour aller plus loin…
-
https://bit.ly/sysmlbook (Work in progress…)
15. Questions de révision
|
Quelles sont les différences entre besoins et exigences ? Quelles sont les différences entre un backlog de produit et une liste d'exigences? En quoi les cas d’utilisation sont-ils complémentaires des exigences? |